Lazer

Les clusters, c'est quand même un sujet assez complexe, voire même le sujet le plus complexe qui puisse exister pour un ingénieur système. Surtout qu'il faut avoir des notions de réseau et de stockage. Pour info, je connais assez bien les clusters IBM HACMP / PowerHA sous AIX. Je connais un peu RedHat Cluster. Et j'ai des notions des clusters VMWare. Donc je peux affirmer que la domotique c'est de la rigolade pour se reposer l'esprit le dimanche à coté de ce que c'est que de faire fonctionner correctement un cluster (encore que le LUA ça peut être bien prise de tête des fois...) Un cluster, quand ça marche, c'est nickel. Mais quand ça veut pas, c'est pire que tout, à tel point que plusieurs entreprises, après une expérience malheureuse avec un cluster, préfèrent faire évoluer leur infra vers une solution sans cluster, malgré tous les beaux discours que le prestataire peut avoir sur les évolution du produit. Le pire que j'ai eu, c'est un cluster que j'ai mis 1 an à faire fonctionner correctement. Et non, je ne suis pas complètement mauvais, puisque le problème était reproductible sur certaines autres clusters (mais pas tous), et j'ai dialogué pendant tout ce temps là avec les développeurs d'IBM aux US qui m'envoyaient les patches à appliquer au fur et à mesure. Parmi les soucis généralement rencontrés : bascule intempestive, pas de bascule du tout, bascule qui ne redémarre pas sur l'autre noeud, temps de bascule anormalement long, etc... la liste est longue J'ai aussi vu des cas particuliers : clusters installés, configurés, recettés et mis en prod. Finalement, aucune bascule durant 3 ans (tant mieux). J'arrive pour faire la migration vers la nouvelle infra, je fais une bascule manuelle préalablement pour vérifier que tout va bien, et là c'est le drame : les évolutions de l'appli font que ça ne bascule pas 3 ans après. Voilà le décors planté... Ce qu'il faut savoir, c'est qu'à la base d'un Cluster, ce n'est pas le système d'exploitation qu'on clusterise (AIX, Linux, Windows, ...), mais les applications qui sont dedans. Par exemple : un serveur Web, un serveur de messagerie, un serveur de fichiers, une base de données, etc... Ensuite, une application clusterisée peut être en mode : - actif/passif (bascule automatique sur le serveur secondaire en cas de crash du serveur primaire) => cas généralement le plus simple à mettre en Å“uvre - actif/actif (tous les noeuds du cluster travaillent, ce qui permet en plus une répartition de charge. Exemples : load-balancer sur un serveur Web, Oracle RAC, GPFS, etc...) => plus complexe à mettre en oeuvre Autre façon de clusteriser, grâce aux hyperviseurs permettant de faire de la virtualisation, c'est de le faire au niveau de la machine virtuelle complète (donc le système d'exploitation complet) comme le fait VMware. Là c'est génial et ça marche assez bien. Je ne connais pas Xen, HyperV, Proxmox & co donc je ne saurais pas dire si ça fait aussi bien. C'est du mode actif/passif. Quelque soit le cluster retenu, la plupart du temps une application partage des données. Donc clusteriser un service c'est bien, mais que fait-on du stockage derrière ? Et bien il faut qu'il soit partagé entre les différents serveurs. Et c'est là que ça devient difficilement gérable pour les particuliers que nous sommes, à la maison. En entreprise, le stockage se fait généralement sur des baies de disques externes, de type NAS (via le réseau Ethernet) ou SAN (via un réseau Fibre Channel dédié, très performant), voire encore d'autres technos (Infiniband, ...) A la maison on commence tout juste depuis quelques années à avoir des petits NAS, alors de là à acheter 2 autres serveurs pour mettre devant et clusteriser l'application, ça commence à être assez violent. A noter que certaines applications peuvent être clusterisées sans forcément avoir besoin d'un stockage partagé. C'est pas exemple le cas d'un serveur Web avec des pages statiques : il suffit de répliquer les pages Web avec un bête rsync entre les 2 serveurs et le tour est joué. Si le serveur Web fait appel à des pages dynamiques (en fait les pages sont statiques, ce sont les données qui sont dynamiques), alors il faut aller chercher les données dans une base MySQL qui devra être clusterisée. Si cette base n'est pas clusterisée, elle devient ce qu'on appel un SPOF (Single Point Of Failure). Et oui, la sécurité d'un système est égale à celle de son maillon le plus faible. Donc en continuant cette logique, où on a 2 serveurs en cluster, et un stockage partagé derrière, on se doit d'assurer la sécurité du stockage. SI on estime que le RAID n'est pas suffisant (car la panne peut venir du contrôleur), alors il faut doubler la baie de stockage..... ah ben voilà on en est déjà à 4 machines physiques en tout... et encore là c'est rien, dans les banques ça devient comique parfois... Après toute cette théorie (pfiou le roman, je suis trop bavard), il faut qu'on se penche que quels sont les services que tu souhaites clusteriser. En fonction de chacun, on verra lequel est facilement clusterisable ou pas. Note : perso, à la maison je n'ai aucune intention de mettre du cluster. Ca sera de la réplication avec rsync pour sécuriser les données. En cas de panne, le redémarrage sera manuel. Actuellement je fais ma réplication sur des disques externes stockées ailleurs. Quand j'aurai un second serveur, je répliquerai en plus entre les 2, ce qui me permettra d'avoir un RPO (Recovery Point Objective) de 24h, c'est à dire au maximum 24h de données perdues (c'est à dire rien du tout pour un particulier).

J'approuve tout àfait ce que vous dites tous les 2. C'est beau, on est tous d'accord

Ah oui là ça dépasse mes compétences... Le souci c'est la garantie, c'est bien pour un vieux volet, mais le miens a une facture de 6 jours.... Pour la solution IPX, j'étais effectivement tombé dessus, mais comme je n'en ai pas, je l'avais tout de suite éliminé, à cause du cout (et je n'en n'ai pas spécialement besoin pour un autre usage). Et puis les fils, j'ai réussi à les tirer sous l'isolant jusqu'à un point où j'ai du 230V en enlevant simplement 3 tuiles par l'extérieur, mais je me vois mal faire la même chose sur une plus grande distance pour aller chercher un IPX. Sur un forum, j'ai aussi vu un gars qui avait des problèmes d'arrêt du moteur avec le 24V DC dans un long câble, il y a des grosses chutes de tension. Alors dans ce cas, il faut tirer des fils de 2,5mm² pour être tranquille.

Did : Oui je sais, la solution avec un FGS c'est un montage où il faut mettre les 2 relais en série, afin d'être certain de ne pas pouvoir faire de court-circuit : http://blog.lbcconcept.fr/wp-content/uploads/2014/04/schema-relais-xdom24.jpg BenjyNet, qu'appelles-tu développer notre propre électronique. Le montage que je tente de faire ne s'appelle pas vraiment de l'électronique, mais c'est quand même un assemblage de composants, qui a l'avantage de parler nativement en Z-Wave. Parce que pour tout recréer en repartant de zéro, c'est quand même pas mal de boulot, et mes souvenirs d'électronique sont quand même assez loin. En plus, je ne suis pas certain qu'on soit capable de réaliser mieux et/ou moins cher que les quelques montages tout fait que j'ai linké dans mon premier message. Coolride, est-ce que tu disposes de quelques composants pour faire des premiers tests ? De mon coté je vais déjà commander les transfos, afin de faire des tests manuellement, avant de les connecter sur un FGRM (qu'il faudra que j'achète aussi)

Nico, tu as déjà ce qu'il faut pour tester ? Moi je n'ai rien en stock dispo, si ce n'est les relais, mais il faut que je les tests car ils sont assez vieux (mais neuf) Did, à ce moment là autant le faire avec un FGS-221, mais on n'aura pas les positionnements intermédiaires. En plus, je ne suis pas certain que le FGRM accepte de se calibrer si le courant est constant, car il ne pourra pas détecter les fins de courses. Ou alors il faut le faire fonctionner en mode Gate (dans la documentation)

J'en ai 3 et je n'ai rien remarqué. En même temps, j'ai dépassé les 30 ans depuis longtemps, je n'entends plus les hautes fréquences, je suis bientôt sourd et aveugle :/

Je pense que c'est comme ma Diagral, complètement fermé. Regarde au catalogue, il doit exister des modules contact sec, qui te permettront de récupérer l'état de l'alarme. Ensuite, un FGS soudé sur une télécommande permettra de la mettre en marche/arrêt. Mais c'est tout, tu ne pourras pas accéder àtoutes les fonctions de l'alarme.

J'y avais pensé àça, mais je ne pense pas que la consommation du relai soit suffisante pour permettre au FGRM de détecter la fin de course. On trouve des transfo pas cher sur eBay, donc en mettre 2 ça ne me dérange pas. D'après les forums d'électronique, pour les VR Velux il n'y a pas besoin d'alimentation stabilisée, ni même de filtrage (condensateur) en sortie du transfo.

Je pense comme Shad. J'en ai un qui s'est tapé un bon délire ce soir, ce qui n'a pas loupé de m'envoyer une notification pour "potential fire" :

Chez moi, j'ai déjà un volet roulant Velux solaire SSL, pilotable par télécommande IO Homecontrol, qui est un protocole complètement fermé. Je vais donc sacrifier une télécommande, et souder un FGS-221 dessus pour le domotiser. Procédure décrite sur ce lien. Ce week-end, j'ai installé un nouveau volet roulant Velux, mais cette fois-ci filaire (gamme SML). Ces moteurs sont alimentés par 2 fils seulement, en 24V continu à inversion de polarité. C'est à dire qu'on envoie du +24V pour le faire monter, et du -24V pour le faire descendre (ou l'inverse, mais ce n'est pas important pour le moment car ce sont juste 2 flls à inverser). Pour le commander, la seule solution commercialisée actuellement par Velux, c'est un bloc transformateur énorme et lourd, avec une télécommande IO Homecontrol, référence KUX 100. Ca vaut assez cher, et en plus ce n'est toujours pas domotisable autrement qu'en sacrifiant la télécommande avec le soudage du FGS-221 comme décrit précédemment. Et bien sur, pas de retour d'état avec cette solution. Autre souci, j'ai branché ce KUX100 sur une prise électrique, à vide (sans y connecter le volet roulant) le boitier consomme 4W. Pour un équipement qui sera branché 24/24, ce n'est pas franchement écologique. A noter que je n'ai pas encore branché ce KUX100 sur mon volet roulant pour 2 raisons : je vais me le faire rembourser si j'arrive à trouver une solution alternative si je le branche, il va reprogrammer le volet roulant dans un mode de fonctionnement propriétaire : au lieu d'être alimenté en 24V par inversion de polarité, il sera alimenté en 24V permanent, avec un protocole propriétaire pour donner l'ordre à l'électronique du VR d'inverser le sens. Une fois ce mode programmé, ça devient totalement indomotisable (heureusement une procédure de reset existe quand même). Donc j'essaie de trouver des solutions alternatives : Module Z-Wave Hunter Douglas DBMZ => Un peu trop cher à mon goà»t, et pas certain que ça soit bien supporté par la HC2. Boitier électronique artisanal Fcosinus => Un peu cher, je n'ai trouvé aucun retour utilisateur, et nécessite en plus un module FGS-221 ou FGRM-222 pour le piloter. Module de commande par Ethernet => a l'air assez sympa, mais nécessite une alimentation 24V en plus, qui va consommer quelques watts Module à relais => moins sympa que la solution IP, et nécessite toujours l'alimentation 24V Module Duwi => pas vraiment convaincu, je ne saurai dire pourquoi. Donc je réfléchi à une solution home-made à base du dernier module Fibaro FGRM-222, qui aurait les avantages suivants : Intégration parfaite aux HC2 / HCL retour d'état faible consommation, le transfo n'est alimenté que lors des montés/descentes commande locale possible par interrupteurs innovant D'après ce que j'ai compris, pour fonctionner, ce module FGRM mesure le courant consommé par le moteur pour détecter les fins de courses. Mais il n'accepte que du 230V sur ses sorties. L'idée serait donc de brancher un transformateur 230VAC/24DC sur ses bornes. Mais comme il y a 2 sens de rotation, il faut en fait 2 transformateurs. Ensuite, afin d'alimenter le moteur selon la bonne polarité, j'envisage d'utiliser des relais doubles afin que seulement un de 2 transfos ne puisse alimenter le moteur. Voir schéma ci-dessous : Selon vous, c'est faisable ? Je ne risque pas de tout cramer ?

Va poser la question dans le topic dédié, ça sera plus simple pour suivre. Idées comme ça : il faut etre sur le même LAN, et il faut entrer le mot de passe dans les paramètres

Je vais encore faire mon rabat-joie, mais : - faut le domotiser le détecteur de brouillage - faut le régler - et pour ça, il faut un brouilleur Donc entre le temps passé, et le cout du détecteur et du brouilleur, autant prendre une alarme NF A2P arrivé àce niveau là.

Moi aussi je suis preneur de toute info Si tu as un retour de Fibaro, n'hésite pas àpartager.

P78, qu'attends-tu précisément d'un cluster ? C'est un peu vague là . Parce que normalement, un cluster ce sont 2 machines (ou plus...) qui partagent le même service (serveur Web, partage de fichiers, serveur de messagerie, etc...), et chacun peut prendre le relai de l'autre automatiquement de cas de crash de l'un d'eux. On parle alors de haute disponibilité. Pas certain que ce soit exactement ce que tu recherches à domicile.

Oui, on utilise le Toolkit HC2 de Krikroff Edit : mouarf, grillé

Vis de diamètre 8, c'est surdimmentionné, ça ne risque pas de tomber Une cheville Molly si c'est du placo aussi c'est top : le plastique va casser avant Le scotch c'est toujours le piège. Facile àposer mais ça ne tiens jamais pour tout un tas de raisons : état de surface, propreté, chaleur etc... Les gens qui posent des alarmes bas de gamme qui sont livrées avec du scotch ont le même problème : ça finit par tomber entraînant des fausses alarmes.

C'est clair que jamais je ne fixerai un truc pareil avec du scotch... J'espère que tous ces bugs seront corrigés par une mise à jour, et qu'il ne faudra pas les renvoyer en garantie.

J'ai aussi constaté ce comportement.

Ouais c'est interdit d'en vendre, mais c'est quand même dans leur catalogue Sinon ça aussi ça déchire : http://www.htshop.fr/product_info.php?cPath=45_56&products_id=1727 Le premier sur batterie, ils ne précisent effectivement pas si il peut brouiller plusieurs bandes de fréquences simultanément, ni la puissance d'émission (parce qu'une distance, c'est assez théorique, on voit ce que donne le Z-Wave et le Wifi en pratique). Donc 15 à 30m, par rapport à ce que je constate avec le Z-Wave chez moi où j'ai plusieurs murs porteurs, ça va faire du 5 à 10m, donc déjà il ne peut même pas brouiller tout le réseau de la maison, en supposant qu'il soit déjà dans la maison quand il allume son brouilleur. Ca confirme ce que je pense : il faut une très grosse batterie pour avoir la puissance d'émission nécessaire en multibande pour neutraliser complètement un système d'alarme/domotique.

Ah oui et un truc tout con aussi, qui n'a rien à avoir avec le brouillage : Dans les scénarios d'alarme, on met généralement le détecteur de la porte d'entrée en temporisation, afin d'avoir le temps de désarmer l'alarme sur le clavier et/ou lecteur RFID avant que ça ne sonne. Les centrales d'alarme sont autoprotégées à l'ouverture/arrachement. En plus la mienne n'est pas accessible sans échelle. Par contre si le mec qui rentre par la porte d'entrée, voit la HC2/Zibase/autre au milieu de la pièce, il aura vite fait de la débrancher et de neutraliser tout le système, onduleur ou pas. Donc faudra penser à planquer la box.

Valable également pour la TNT parait-il...

Ah oui, et aussi pour les brouilleurs, ça couvre toutes les fréquence qu'on veut bien couvrir... il suffit d'acheter ou de se fabriquer le modèle désiré. Donc du coup, la consommation explose.... et Lolomail confirme qu'il faut effectivement pas mal de puissance. Mon transmetteur GSM est sous le faîte du toit et en visée directe de l'antenne-relai à moins de 100m, donc déjà il va en falloir de la patate pour le brouiller celui-là .

Oui, j'y ai pensé àmettre des modules universels dans les PIR, mais ça pose 2 problèmes : - il faut du 9V mini, donc alimentation supplémentaire àprévoir - perte de la certification NFA2P

Si je résume, ce sont les capteurs qui sont armés, et non pas l'alarme générale. Il me semble avoir déjà vu ça quelque part sur ce forum. Effectivement, c'est pensé à l'envers par rapport à un système d'alarme classique, mais ça permet de faire des scénarios poussés : mise en marche partielle de telle ou telle zone, etc...

Il va aussi chercher ça : /api/interface/data Pas certain que ça réponde à toutes tes questions, mais c'est peut être un début de piste...