Lazer

Architecture matérielle Configuration des nœuds du cluster Les 3 nœuds n'auront pas la même configuration matérielle, même si l'architecture sera la même afin de permettre une migration des VM et applications entre chacun des 3 nœuds. A ce sujet, il est essentiel d'utiliser des processeurs de la même famille (= même jeu d'instructions) afin de permettre aux VM qui s'exécutent sur un noeud de pouvoir migrer à chaud d'un serveur à un autre. Sans cela, la migration à chaud est impossible et doit se faire à froid, afin qu'au redémarrage la VM découvre le jeu d'instruction du serveur cible et s'adapte en conséquence. Comme mon cahier des charges est de monter une infrastructure la plus résiliente possible, j'ai fait le choix de m'orienter vers des composants "professionnels", à savoir pas des produits issus du monde grand public qu'on trouve dans les PC classiques. Je sais que plein de personnes montent des serveurs avec des composants grands publics et que ça fonctionne très bien, mais quand on creuse le sujet (sur les forums spécialisés Reddit, etc) on s'aperçoit qu'il y a toujours un moment où c'est instable, ça plante, ou bien qu'il faut remplacer un composant de manière prématurée. Je le disais, je cible au moins 15 ans de durée de vie pour ce système, pas question que ça lâche avant. En réalité, dans le langage marketing moderne, ce n'est pas le terme "pro" que je devrais utiliser, mais "entreprise". Tant pis pour l'abus de langage. Surtout, j'ai besoin de certaines caractéristiques des composants pro pour le bon fonctionnement de mon système. En vrac : une interface IPMI sur la carte mère pour la gestion à distance (équivalent ILO, iDRAC, IMM2, etc) de la RAM ECC pour la correction d'erreur, particulièrement pour TrueNAS qui utilise massivement la RAM comme cache disque pour les performances des SSD avec PLP intégré (Power Loss Protection), totalement indispensable pour CEPH une connectivité réseau 10 Gb/s pour la réplication CEPH J'ai longtemps voulu partir sur des processeurs AMD EPYC 4005 Grado (architecture Xen5), cependant j'ai renoncé à cause de la consommation élevée au repos (en idle) de ces processeurs. Je suis donc revenu au classique choix Intel Xeon 6, qui permet des optimisations poussées pour descendre assez bas. Il s'agit avant tout d'un homelab, qui aura une très faible activité la majeure partie du temps, donc j'ai privilégié le choix raisonnable de la consommation électrique réduite. C'est dommage d'un point de vue performance, car pour le même prix on a quasiment 2 fois plus de performances chez AMD, de son coté Intel est clairement à la traine. Le 1er nœud, qui portera la VM TrueNAS, sera le mieux équipé. Les 2 autres nœuds seront moins richement dotés, ce qui permet de réduire la facture d'achat, et déjà plus que suffisant pour mes besoins actuels (et même surdimensionné...). Mais si le besoin s'en fait sentir plus tard, je pourrai toujours faire évoluer leur configuration (ajout de RAM, stockage, etc... voire remplacement du CPU). Nœud n°1 : NAS Gros boitier rackable 19" Gros CPU RAM 32 Go Carte SAS pour connecter tous les disques durs Nœud n°2 Petit boitier rackable 19" Petit CPU RAM 16 Go Nœud n°3 Boitier Mini-ITX Petit CPU RAM 16 Go Comme on le constate, les 2 premiers nœuds seront en boiter rackables 19", destinés à être installés à la cave dans un futur rack à venir. Tandis que le 3ème nœud dans un boitier compact au format Mini-ITX, l'objectif étant de le déporter au rez-de-chaussée, dans le placard qui héberge actuellement mon Micro-serveur Gen8. En effet, j'ai besoin d'y connecter une antenne EnOcean en USB car j'ai encore quelques modules utilisant ce protocole. Demain, si je déploie du Home Assistant, je pourrai également y connecter une antenne Z-Wave, Zigbee, Thread, Whatever... sauf si j'utilise une antenne déportée Ethernet POE, mais en tout cas je en serai pas embêté par la portée radio. Réseau Chaque carte mère dispose de 2 connexions 1 Gbit/s sur ports RJ45. Je vais ajouter en plus une carte d’extension PCIe à 10 Gbit/s sur chaque nœud, avec slot SFP afin d'y brancher des câbles DAC. J'ai déjà expliqué que j'évite le 10 Gb sur port RJ45 à cause de la consommation et donc de la chauffe très importante. L'utilisation de câbles DAC est bien plus efficient d'un point de vue énergétique, mais aussi financier (si le câble DAC coute plus cher que le câble RJ45 Cat 6a, le gros gain se fait sur le coût des ports coté serveur et coté switch). En plus, le câble DAC est la solution présentant la plus faible latence, et cet aspect est particulièrement important pour les performances de mon réseau de réplication CEPH, car chaque écriture d'une VM sur un nœud ne sera acquitté que lorsque l'ensemble des 3 nœuds auront validé l'écriture sur leur SSD local. J'ai même pensé à utiliser du 25 Gbit/s, pas tant pour le débit, que pour la latence encore plus faible, mais d'une part je n'ai pas trouvé de prix intéressant, et d'autre part ça aurait augmenté la consommation électrique. On verra dans le futur si l'utilisation de 25G s'avère nécessaire, je pourrai toujours remplacer les cartes PCIe. Pour économiser un peu, et puisque je n'ai pas besoin de 10G pour les VM des nœuds 2 et 3, celles-ci utiliseront le réseau 1G pour la connectivité externe. Le nœud TrueNAS, lui, a besoin de connectivité rapide pour les échanges de gros fichiers, donc du 10G pour ne plus être bridé par ma connexion interne fibrée de 8 Gbit/s (même si je suis bridé à 5 Gbit/s réels par mon routeur avec IDS/IPS activité) Donc pour chaque nœud, j'ajoute la carte 10G suivante : Nœud n°1 : 4 x 10 Gbit/s Nœud n°2 : 2 x 10 Gbit/s Nœud n°3 : 2 x 10 Gbit/s Le réseau CEPH entre les 3 nœuds sera de type Full Mesh, c'est à dire que chaque nœud communique avec son voisin en connexion directe point à point, sans passer par les switchs. Cette architecture est absolument critique pour la haute disponibilité du cluster dans mon projet, car sinon un reboot du switch (par exemple lors d'une mise à jour de firmware) ferait tomber l'ensemble du cluster en quelques secondes. En outre, cette connexion point à point permet également de gagner de précieuses micro-secondes de latence, comme évoqué précédemment pour la réplication. Enfin, cela permet d'économiser des ports coté switch, donc réduit très significativement la facture, et permet également de grappiller encore quelques watts de consommation électrique. Sur le nœud hébergeant TrueNAS, les 2 ports 10 G seront agrégés en LACP, non pas que ça soit indispensable, mais puisque j'aurai 2 ports disponibles, autant les utiliser. En outre, cela apportera de la redondance entre les 2 liens, même si à l'extrémité ce sera connecté au même switch. Le 1er port RJ45 de chaque nœud sera dédié au management du cluster, ainsi qu'au réseau Corosync, qui permet au cluster Proxmox de communiquer (détection des pannes entre nœuds du cluster). Comme il n'y aura pas de traffic VM sur cette interface, peu de chance de saturer le lien et donc de faire tomber ce lien Corrosync. Le 2nd lien Corosync sera lui sur le même réseau Full-Mesh que CEPH, là encore pour s'affranchir d'une indisponibilité du switch qui ferait tomber le cluster Proxmox (il y a 2 clusters en fait dans mon infrastructure, celui de Proxmox, et celui de CEPH). Selon le nœud, les 2 liens 10G LACP ou le 2nd lien 1G RJ45 seront utilisés pour le bridge portant le traffic des VM, avec les différents VLANs taggués (DMZ, etc) Une dernière remarque sur les câbles DAC, on est limité à une distance maximal de 3m avec un câble passif (au delà il faut passer sur du câble actif, c'est à dire avec fibre optique et conversion/amplification aux extrémités, c'est couteux et consommateur). Cela ne pose pas de souci, les 2 serveurs dans le rack seront connectés avec un câble DAC court de 50cm, tandis que le nœud 3 situé à l'étage juste au dessus sera interconnecté avec des câbles de 3m. Note : la connexion d'administration IPMI 1G RJ45 dédié sur la carte mère n'est pas représentée sur le schéma car n'entrant pas dans le fonctionnement du cluster, il n'y a pas de transfert de données dessus. Stockage Je l'ai dit précédemment, les SSD seront de type pro (ou plutôt enterprise), c'est à dire qu'ils doivent disposer de la fonctionnalité PLP (= Power Loss Protection) qui sont des petits condensateurs embarqués dans le PCB, à coté du contrôleur et des puces de Flash, pour secourir la mémoire tampon en cas de panne d'alimentation, pour prévenir toute perte de données qui ne seraient pas encore physiquement écrites sur les puces Flash NAND, ce qui entraine inévitablement une corruption des données lors du redémarrage. Ce point est essentiel pour CEPH, qui réalise toutes ses écritures en mode synchrone (flag O_SYNC) pour garantir la cohérence des données écrites (rappel : recherche de la fiabilité ultime). Sans PLP, donc avec un SSD grand public (y compris les modèles commercialement estampillés "Pro" de Samsung ), le SSD désactive son cache en écriture et il se passe alors 2 choses : Effondrement des performances : on parle potentiellement d'un rapport 100 à 1000 Usure prématurée : le wear-leveling étant désactivé par l'absence de cache en écriture, les cellules TLC ou QLC s'usent d'autant plus vite. Sur les forums, j'ai vu des gens dont les SSD grand publics utilisés avec CEPH sont morts en quelques semaines à quelques mois, 1 an tout au plus. Donc quand je vois des tutos sur des blogs ou chaines YouTube qui expliquent comment monter un cluster CEPH avec des SSD à pas cher, ça me fait doucement rigoler, ou ça m'attriste c'est selon, car ça démontre bien qu'au delà de la démonstration, ils n'ont pas dû l'utiliser bien longtemps leur cluster... A noter que même sans activité des VM, CEPH écrit en permanence des logs sur les SSD, ce qui les use même sans activité, simplement en restant allumés ! Donc chaque serveur disposera de 2 SSD : NMVe M.2 de 480 Go sur carte mère : boot Proxmox et Monitor CEPH NVMe U.3 de 1.9 To sur port Oculink PCIe x4 : disque OSD pour CEPH et DB/WAL En plus, le nœud 1 TrueNAS disposera de 3 autres SSD SATA grand public classiques de 4 To chacun : Pool local Proxmox pour les VM qui n'ont pas besoin de la haute dispo apportée par CEPH System Dataset pour TrueNAS : permet à TrueNAS d'écrire ses logs sur ce SSD et ainsi de permettre aux disques durs mécaniques de rester en veille prolongée, ce qui réduira significativement la consommation électrique de ce serveur (compter 5W par disque en rotation sans activité, multiplié par les nombre de disques, ça fait vite pas mal...) VM Synology : pour Surveillance Station. Alors certes un SSD pour de l'enregistrement vidéo c'est luxueux, mais j'ai réussi à en avoir un pour pas trop cher et ça consommera beaucoup moins qu'un disque dur dédié à cet usage la VM TrueNAS disposera d'une carte PCIe de type HBA (= Host Bus Adapter), c'est à dire sans fonctionnalités RAID intégrée, affectée en PCI Passtrough. L'objectif étant que TrueNAS, et plus particulièrement ZFS, puisse disposer d'un accès direct aux disques durs (informations SMART, etc), pour gérer le RAID logiciel avec un Pool en RAIDZ2, c'est à dire protégeant contre la perte de 2 disques. C'est important, car avec 1 seule protection, le risque est grand de perdre un second disque pendant la reconstruction, surtout avec des disques capacitifs de 24 To. Alimentation électrique Il est inutile d'avoir un cluster haute-dispo à 3 nœuds si une simple panne d'alimentation électrique vient tout casser. J'ai donc réfléchi à une solution pour apporter de la redondance électrique. Bien sûr, il est possible de trouver des alimentions ATX redondantes, mais ce n'est pas l'approche que j'ai retenu car : Couteux Choix limité de modèles Double alimentation dans le même format standard ATX, donc ventilateurs plus petits et donc bruit important Pas de solution existante pour mon boitier Mini-ITX déjà ultra compact Quand j'ai mis en place ma batterie de stockage solaire, j'avais anticipé la possibilité d'utiliser le réseau 48 V à courant continu, directement câblé sur la batterie elle-même. J'ai déjà convertisseur DC-DC 48V vers 12V pour un détecteur de fumée, je vais donc ajouter un autre convertisseur Victron 12V pour alimenter l'un des nœuds. Ce sera le nœud n°3, dans le boitier compact Mini-ITX. Ce serveur n'aura donc pas d'alimentation AC classique, mais un connecteur DC 12V. Je reviendrai en détail plus tard sur ce montage lors des discussions sur le choix des composants. L'autre intérêt de l'alimentation direct en courant continu, c'est le rendement élevé. En effet, on évite la double conversion DC-AC puis AC-DC, avec des pertes significatives à chaque étape. Les 2 boitiers rackables auront une alimentation ATX standard, haut-rendement, afin de limiter les pertes. Là encore, je détaillerai ultérieurement le choix du modèle. Chaque alimentation sera sur une source d'alimentation 230V AC différente. Le nœud n°1, le principal qui est dédié au NAS, sera derrière mon vaillant onduleur Eaton 5P qui protège déjà mon informatique à domicile. Bien sûr je ne mets pas 2 nœuds derrière le même onduleur Eaton, car une panne de celui-ci entrainerait la perte des 2 nœuds et donc du cluster entier. Donc le nœud n°2 sera branché directement sur le secteur, enfin plus précisément sur la sortie secourue de l'onduleur Victron (comme toute la maison), ce qui le protège donc contre une coupure de courant EDF. Ultérieurement, quand UniFi sortira sa gamme d'onduleurs "pro" (avec batterie Li-Ion), j'en prendrai un pour sécuriser encore plus ce serveur. De façon générale, on constate qu'en cas de coupure secteur EDF, l'ensemble des 3 nœuds de mon cluster (ainsi que les switchs, routeur, etc) sont tous protégés. Si la batterie est chargée et/ou qu'il y a suffisamment de soleil, je peux théoriquement tenir un temps infini.

Oui mais c'est ultra limité, compatibilité Onvif uniquement, pas de reconnaissance d'événements par IA.... Aucun intérêt en pratique, c'est juste de l'enregistrement bête et méchant, ça revient presque à la solution Synology Surveillance Station. Ils proposent un module externe pour ajouter l'intelligence aux caméras lamdba, mais financière ça n'est pas vraiment intéressant, autant acheter directement les caméras Unifi. Franchement, je ne te dis pas que tu dois t'enfermer dans une marque, mais regarde ce que propose vraiment l'offre Unifi Protect avec les caméras récentes G6, tu verras qu'ils ont carrément pris plusieurs années d'avance sur Sylonogy. Et les interactions avec les portiers et contrôles d'accès de la même marque, c'est bien foutu. Moi ça me fait réfléchir, et je pense qu'à l'avenir je basculerai sur cette solution. En attendant je n'achète plus de caméras Hikvision (j'en ai déjà assez de toute façon) Et comme dit, mon nouveau serveur aura une VM Syno uniquement pour conserver Surveillance Station quelques temps, le temps de voir comment je fais évoluer ma vidéosurveillance.

En fait, si tu compares ce qui est comparable (hors piratage) : des caméras Hikvision de qualité + un NAS Synology + les licences Surveillance Station des caméras Unifi G6 + un NVR Unifi + aucune licence Tu verras que Unifi n'est plus plus cher, et même moins cher, mais avec une interface bien plus évoluée, une intégration IA native (alors que Hikvision + Surveillance Station c'est bancale comme tout....). Attention je parle bien des caméras UniFi G6, la qualité d'image est excellente, la reconnaissance IA assez fiable, rien à voir avec les générations précédentes. Du coté de chez Hikvision, il faut commencer à mettre assez cher pour avoir l'équivalent.... presque aussi cher en fait. Je vais me faire démonter par notre fanboy Synology du forum, mais si tu fais le tour des autres forums, chaines YouTube, groupes Facebook (bon OK pas très crédible celui-là), tu verras que Synology est complètement à la dérive, ils ne tiennent plus la comparaison. Reste que Syno a une solution NAS tout intégrée, fonctionnelle et ergonomique, c'est probablement tout ce qu'ils leur reste. Mais bon là encore, quand tu vois la vitesse d'évolution des NAS Unifi, ce discours ne tiendra peut être même plus d'ici 1 an.

En boitiers, Silverstone c'est le top qualité, avec un choix incroyable de modèles rackable ou tour, certains sont même montables dans les 2 configurations. Comme tu dis, le vrai problème c'est la RAM, regarde l'évolution du prix des barrettes que j'utilise, sachant que j'en ai 4 des comme ça; j'ai mis le curseur au moment où je les ai acheté : Fait attention, il faut vérifier, mais j'ai peur que partir sur du Xeon risque de t'imposer de la RAM ECC, et avec les prix actuels, ce n'est plus possible. A ta place, je choisirais en premier la RAM, et en fonction de ce que tu trouves, tu montes le serveur autour. Donc après la RAM, tu choisi la carte mère, processeur, etc... peut être qu'au final ça ne sera pas de Xeon mais du Core quelque chose, avec un socket différent de LGA1700. En plus, si la consommation est importante pour toi, un Core descendra plus bas qu'un Xeon (gamme pro, optimisé pour la perf...) Attention aux SSD aussi qui ont déjà méchamment augmenté, c'est pour ça que j'avais fait un peu de stock avec mes 20 To de SSD..... Il t'en faut au moins un pour le disque de boot et le datastore des VM. Pour Surveillance Station, après des mois de réflexion j'ai trouvé comment je vais faire : - dans un 1er temps, monter une VM Xpenology dédiée exclusivement à Surveillance Station (équivalent à ce que j'ai actuellement sur mon HP Gen8 en fait) - dans un second temps (l'année prochaine ?) : tout basculer en Unifi, ce qui implique d'acheter un NVR de la marque (surement le modèle UNVR), mais aussi leurs caméras (la gamme G6 est top) De toute façon aujourd'hui, Synology s'est endormi sur ses lauriers. Plus d'évolution de Surveillance Station, tandis que Unifi avance à une vitesse folle, quand tu vois l'interface et les capacités d'IA, ça dépasse déjà Syno. Mais l’investissent financier initial est assez important. Avec la pénurie des composants, c'est pas le bon moment pour se monter une nouvelle machine, tu t'y prends au mauvais moment (mais ça sera encore pire dans quelques mois....) Sinon, j'ai reçu mon Xeon, je peux commencer à monter le nœud principal ce week-end

Désolé j'ai pris du retard dans mon descriptif, oui j'ai déjà quasiment tout commandé et reçu, il me manque juste le dernier processeur Xeon que je suis censé recevoir avant-hier hier aujourd'hui si UPS se décide à travailler.... Le plus gros Xeon, celui qui doit aller dans mon nœud principal qui aura tous les disques durs et la VM TrueNAS. Les 2 autres (petits) nœuds sont déjà montés, installés et opérationnels.... mais pas utilisables, car un cluster haute-disponibilité de 3 nœuds avec seulement 2 nœuds, c'est pas prêt à entrer en production. Mais déjà, oui c'est bien du LGA1700, et coté carte mère j'utilise ça : Mini-ITX : 1 x ASRock Rack EC266D2I Micro-ATX : 2 x ASRock Rack EC266D4U La EC266D4-4L c'était mon premier choix pour le nœud NAS grâce à son nombre de slots PCIe qui m'aurait permis d'ajouter des cartes plus tard (notamment un GPU si jamais j'avais l'intention de faire de l'IA locale plus tard par exemple), sauf qu'elle était totalement indisponible en Europe entière tout l'hiver... et là elle est de nouveau en stock. Pas de chance. Si ton boitier te permet de monter une carte mère au format ATX, c'est clairement le meilleur choix, car plus évolutif coté entrées/sorties. Pour le 10 GbE, c'est ce que je voulais initialement intégré à la carte mère, mais comme je l'ai rapidement expliqué j'ai changé d'avis et c'est un grand NON maintenant, car le 10 GbE sur port RJ45 cuivre c'est une plaie sans nom : consommation (et chauffe) très importante, plusieurs Watts perdus (jusqu'à 5W par port) en continu, qu'il y ait de la communication réseau ou non. C'est pour ça que je ne vais utiliser que du 10 G avec câbles DAC, d'une part c'est moins couteux, et d'autre part la consommation est plus faible (compter 0.5 W par port, c'est imbattable), et en prime la latence est plus faible (et ça c'est important pour mon réseau de réplication CEPH) Donc 1G RJ45 sur la carte mère pour l'administration de Proxmox, et carte PCIe Intel X710-DA2 ou DA4 pour les connexions 10G DAC. Ce modèle de carte Intel en particulier est celui qui propose la plus faible consommation. J'ai trouvé des clones à pas cher sur Aliexpress pendant le Black Friday (chipset Intel original, juste le PCB qui est un design chinois générique). Idem pour la carte SAS Broadcom d'ailleurs, qui va gérer les disques durs. La consommation à vide pour l'instant oscille entre 25 et 40W par nœud, mais ça ne t'avance pas beaucoup car je n'ai pas encore décrit la configuration matérielle détaillée, et je n'ai pas encore appliqué toutes les optimisations permettant de réduire la conso (BIOS, ASPM, C-States, vitesse des liens PCIe, paramétrages noyaux Linux, etc). Je détaillerai ça plus tard de façon détaillée, quand j'aurai joué avec. Et cette consommation n'est pas tout à fait "à vide", car sur chacun de ces 2 nœuds il y a aussi : la carte réseau Intel X710-DA2 10G un SSD NVMe de gamme pro de chez Kinston sur le slot M.2 un SSD NVMe de gamme pro de chez Micron au format U.3 (raccordé sur un port Oculink PCIe x4 de la carte mère) qui consomme déjà 5W rien qu'à lui tout seul en idle, sans activité.... c'est un monstre de puissance. Forcément, ce luxe que je me suis imposé a un cout énergétique certain. des ventilateurs (ventirad+boitier), même si en ne prenant que des Noctua, la consommation est très faible, surtout piloté en PWM à rotation lente Je précise que les SSD sont tous de gamme professionnelle, j'en parlerai de façon plus détaillée plus tard, mais ça a son importance sur la consommation : dans le monde pro, on se moque de la consommation, on cherche fiabilité + performance. Rien à voir avec les SSD Crucial, Samsung, et compagnie qu'on installe dans nos PC classiques, dont la faible consommation est le critère n°1. En terme de consommation, il y a un rapport 1 à 10, voire 1 à 100 selon l'activité I/O entre les gamme grand public et pro. Je l'avais dit ton mon cahier des charges, je privilégie la fiabilité, et la performance, bien avant la consommation. C'est pour mon projet, ce n'est pas ce que je te recommande, c'est pour ça que je prend le temps de décrire mes chois et les conséquences.

Après la mise à jour, on a une nouvelle notification qui nous conseille de préparer la migration vers le moteur Z-Wave v3 car le moteur v2 ne sera bientôt plus mis à jour : Quand on clique sur le bouton on arrive au panneau Z-Wave qui nous propose de lancer la migration : Mais, comme le rappelle @jojo, c'est pas comme si le moteur v3 était vraiment stable, comme le mentionne encore le Changelog : Du coup.... faire la migration pour passer d'un moteur non maintenu à un moteur non finalisé. C'est jouer aux équilibristes ! Bon, le message sur la box nous dit qu'on peut toujours revenir à une sauvegarde précédente, c'est un peu rassurant... en effet, la configuration des différents modules dans le réseau Z-Wave ne devrait théoriquement pas être affectée par cette mise à jour coté box / contrôleur. J'ai 2 modules Z-Wave sur ma box de test, j'attends la sortie de la version Stable du firmware puis je tenterai alors la migration Z-Wave. Pour ma box de prod, rendez-vous dans.... euh..... bah..... on verra

J'avoue que.... tout pareil Mais quand même, je suis impressionné par les dernières mises à jour Fibaro / Nice : ajout du KNX, enfin la tant attendue migration Z-Wave v2 vers v3, on se demande quelle sera la prochaine étape. Allez rêvons un peu, un support amélioré du Zigbee, ou même du Bluetooth Low Energy comme annoncé initialement

Après, de toute façon perso je ne crains plus rien, entre la température extérieure, l'allongement de la durée des jours, les 2 PAC (dont 1 seule fonctionne en ce moment), les panneaux solaires et la batterie, même s'ils balancent 13 jours rouges d'affilée je ne les sentirai pas passer.

J'ai vu passer ça hier, si ça se confirme ça rendrait TEMPO comme le meilleur bon plan cette saison

Ce n'est pas tant le nombre de modules qui importe, que la présence de certains modules problématiques. J'ai aussi eu le coup du ZXT 120 buggué qui a fini au fond d'un tiroir, également avec un RGBW (1er firmware, avant les mises à jour, donc corrigé maintenant) Sinon hors bug, les Wall Plugs Fibaro peuvent être extrêmement bavards, j'ai eu le cas sur mon frigo et mon congel, tout deux à très basse consommation, de très légères variations de la consommation en permanence, floodaient mon réseau. J'ai corrigé en ajustant les paramètres de remonté de la mesure de puissance. Voir la doc du module. A l'époque j'avais utilisé une scène partagé sur le forum officiel pour la HC2, mais je ne sais pas si cette scène a été portée sur HC3. Il existe maintenant des outils de diagnostiques intégrés dans la HC3 permettant d'identifier les modules les plus bavards, comme l'indique @ericl78 J'ai 108 modules Z-Wave pour ma part.

Hein ??? Tu dois avoir un gros problème quelque part car ce n'est clairement pas normal, je n'ai pas de retard de réaction dans la gestion des éclairages. Soit je suis en association direct et alors c'est instantané (en tout cas non perceptible pour nous autres humains), soit ça passe par la box (GEA) et alors le délai est de l'ordre de la demi-seconde. Là oui c'est perceptible, mais tout à fait acceptable et en tout cas certainement pas plusieurs secondes. Peut être que ton problème est une saturation du réseau Z-Wave, et alors même si tu bascules sur HA, tu auras le même problème, il te faut donc résoudre ce problème. Si c'est bien de ça dont il s'agit, il faut identifier le (ou les) module qui inondent le réseau.

Ah... très étrange. Bon bah finalement tant mieux alors.

Je n'ai aucun souci chez moi avec mon Roborock. Tu aurais peut-être fait une mise à jour de tes robots récemment ?

Pas testé perso. Bien sûr que la clusterisation de la VM domotique est tout à fait surperflue... encore que, sur les forums, ça en parle pas mal, et c'est logique : HA est un truc de geek, tu le mets dans une VM c'est un truc de geek parce que ça te permet (entre autre) de faire des backups et snapshots facilement pour fiabiliser ton infra en cas de crash, du coup la clusterisation c'est l'étape geek suivant immédiatement. On y vient vite. Et la démocratisation de ces antennes Ethernet participe bien à tout ça ! Avant l'apparition de ces clés, il fallait utiliser un Raspberry PI, voire un ESP, avec la clé USB branchée dessus... maintenant avant l'antenne Ethernet POE, c'est tout intégré, moins cher, plus fiable, alimenté par 1 seul câble, et transmission ultra fiable car Ethernet, pas de Wi-Fi. Et comme dit, l'autre usage, c'est simplement de pouvoir profiter du réseau Ethernet pour déporter l'antenne où on veut dans la maison, déjà rien que ça c'est un gros bénéfice pour certaines installations.

En fait avec HA, on peut utiliser des clés (Z-Wave, Zigbee, Thread) sur un port USB, c'est le cas classique, et alors si la machine qui fait tourner HA plante, alors il faut manuellement débrancher/rebrancher la clé USB sur une autre machine. A coté de ça, il existe des antennes en Ethernet (POE tant qu'à faire, le même câble fait alimentation et transfert de données), ce qui permet au chipset (Z-Wave, Zigbee etc) d'être directement interfacé avec une instance HA par le réseau. Je ne pense pas que 2 instances HA puissent se partager la même clé simultanément (et puis de toute façon, même sans antenne radio, comment gérer 2 instances HA ???). Mais il est tout à fait possible de mettre l'instance HA dans une VM, sur un cluster Promox composé de 2 nœuds ou plus, et à ce moment là on a mis HA en HA (Home Assistant en High Availability, faut suivre ). L'instance HA, unique, est alors active sur 1 seul nœud à la fois (1 nœud c'est une machine physique, donc un PC, un serveur, un NUC, peut importe), et peut automatiquement redémarrer sur l'autre noeud en cas de panne du premier noeud. L'antenne radio étant accessible par le réseau Ethernet, pas besoin de la déconnecter, elle est automatiquement reconnue. Plus simple, si on n'a pas 2 noeuds qui fonctionnent en parallèle (cluster), mais 1 seul, si la machine tombe en panne, il suffit de restaurer sa configuration sur la même (si réparée) ou une autre machine et on repart comme avant. Si l'antenne est sur clé USB il faudra la reconnecter physiquement, si l'antenne est en Ethernet, il n'y a rien à faire. Sans même parler de cluster haute-dispo, l'antenne Ethernet dispose d'un autre avantage : pouvoir la déporter loin de la machine faisant tourner HA, par exemple si celle-ci est installée dans un rack métallique et/ou à la cave. Faire la même chose en USB est plus délicat, car il faut passer un câble dédié, et de toute façon on est vite limité par la longueur du câble USB.

Si, en France aussi (malheureusement j'ai envie d'ajouter, car c'est un système bourré de limitations... plafonds quotidiens, reports annuels, etc) En plus c'est facturé fort cher aux commerçants (plus que les CB), donc au final on paye notre repas plus cher, car faut pas rêver, le surcout est réintégré dans le prix des plats. Je ne suis pas sûr d'avoir la réponse à toutes tes interrogations... il faudrait aller lire le code de GEA pour bien comprendre... il faut du temps... et de la motivation. Déjà @jojo t'a donné une bonne indication sur la possibilité d'exploiter les #value[1]#, #value[2]# etc Cependant, pour moi, ce sont des alias destinés à être remplacés par leur valeur correspondante uniquement dans les messages textuels, c'est à dire ce qui est affiché / envoyé en notification. Et donc... pas dans les conditions (ce que tu cherches à faire). Moi j'utilise de plus en plus "Function", tant en condition qu'en action, car c'est ultra puissant, ça permet de lever toutes les limitations des conditions et actions de GEA. Dans une Function, on code en LUA traditionnel, littéralement comme dans un QuickApp. On peut aussi récupérer les valeurs des conditions de GEA. Exemple, c'est bidon car ça retourne la température de la météo divisée par 2, mais c'est pour montrer un exemple simple d’imbrication des options : {"Function", function(a, b) return (a+b)/2 end, {"Weather", "Temperature"}, 20} L'étape d'après, c'est créer ses propres options (conditions et/ou actions) à décrire dans function config(GEA) Et là c'est no-limit, on peut littéralement écrire l'équivalent d'un QuickApp complet sur plusieurs dizaines ou centaines de lignes. Par exemple j'ai toute ma gestion d'optimisation du chauffage (en fonction du surplus solaire disponible) qui fonctionne comme ça. C'est expliqué brièvement dans la doc de syntaxe au chapitre "PLUGINS INTERNES GEA" (lignes 2069 et suivantes)

Je ferais ça avec "Function" en condition, qui fait le test de la date en LUA "à la main" et retourne true/false pour déclencher les actions de la règle.

Oui c'est ce que je fais avec mon Victron, je limite le courant de décharge, ça permet de travailler dans la zone de meilleur rendement, et évite de décharger toute la batterie trop rapidement. Après il faudra que tu regardes le rendement global, charge+décharge, c'est ça qui est intéressant. Combien de kWh tu rentres dans la batterie, versus combien tu en récupères en sortie.

Hum, oui mais 83% ça doit être le rendement théorique maximal aux conditions idéales de température, de courant de charge, et de décharge. Perso avec mon système Victron + Pylontech, j'ai pu monter à 86% de rendement, dans les conditions idéales, ce qui correspond aux abaques fournies par Victron : charge à 1390W et décharge à 1100 W constants. Autant dire que ça n'arrive jamais, sauf dans des conditions très particulières : l'hiver, lorsque je force la charge la nuit depuis le réseau, et que le lendemain est froid et totalement sans soleil avec chauffage qui consomme plus de 1100W. Donc la batterie absorbe bien le delta. Typiquement, ce sont certains jours Tempo Blancs de novembre/décembre/janvier... donc pas très souvent au final. Car sur l'année complète (j'ai 11 mois d'historique, mais ça ne va pas changer énormément sur mars), je suis à une moyenne de rendement de 77.5 % En effet, dès que le soleil sort, on ne maitrise plus les courants de charge/décharge, car tout dépend du surplus solaire, et de la consommation de la maison en dent de scie. Donc le rendement s'effondre. Le pire mois, c'était novembre, avec seulement 68.3% de rendement...

Oh une Marstek ! Tu regarderas si tu peux calculer le rendement de charge/décharge de la batterie ? C'est c'est une information qui est systématiquement oubliée sur les batteries Plug & Play.

C'est surtout que si on met un disque de 22 To dans une grappe de disques 24 To, alors tous les disques sont limités à 22 To, donc ça fait pas mal de place perdue (2 To x le nombre de disques de 24 To), et donc autant argent perdu. Les contraintes du RAID.... c'est une des nombreuses raisons pour lesquelles je n'avais jamais fait de RAID jusqu'à présent dans mes serveurs à domicile, c'est beaucoup de contraintes pour un bénéfice faible voir inexistant pour un usage domestique. Rappel : le RAID n'est pas une sauvegarde. A se répéter en boucle.

Merci, mais dommage ce n'est que 22 To.... je ne vise plus que le 24 To maintenant pour uniformiser ma prochaine grappe RAID avec ZFS.

Euh, tu ne dois pas connaitre Supermicro pour dire ça Après c'est vrai que la marque est très peu représentée en France, donc ça n'aide pas à la valoriser, face aux volumistes DELL, HPE, Lenovo & co. D'ailleurs puisque tu en parles, pour mon projet perso de nouveau serveur, j'ai laissé tombé Supermicro, car justement, c'est de plus en plus difficile de se procurer leurs machines en France... et en Europe de façon générale. On dirait qu'ils sont en train de déserter le marché européen, en tout cas c'est l'impression que ça me donne. Peut être à cause des taxes US, mais c'est étonnant, car c'est dans l'autre sens normalement... Du coup je me suis rabattu sur ASRock Rack (la gamme pro de ASRock, le fabricant de carte mère grand public bien connu). Bon là ce n'est plus américain, mais du bon vieux Taïwanais, remarque c'est devenu un gage de qualité maintenant, le made in Taïwan low-cost c'était dans les années 80... Pas encore beaucoup utilisé, mais pour l'instant ça fonctionne bien, rien à redire L'IPMI complet sans licence (contrairement à HPE ILO....) permet de manager 100% du serveur à distance, et même la gestion des différents ventilateurs du serveur est ultra personnalisable, un point faible de Supermicro d'ailleurs (et personnalisation complètement inexistante chez HPE......) Ah oui, et aussi, les firmwares sont librement accessibles bien sûr Quant aux Chinois, bah écoute... Lenovo n'a plus rien à prouver, et personnellement, je préfère cette marque à HPE et DELL, mais c'est à cause d'une vieille habitude que j'ai prise à l'époque où ces serveurs provenaient de chez IBM, jusqu'en 2014... le temps passe vite ! De toute façon, tant qu'on reste dans le x86, peut importe la marque, au final c'est toujours la même chose : un processeurs Intel ou AMD, de la RAM de l'un des 3 fabricants mondiaux, idem pour les SSD.... il n'y a que la couleur de la façade qui change Ou alors Huawei, jamais testé perso. De toute façon, c'est une marque tellement peu représentée en France, que trouver du matos à titre perso doit être encore plus compliqué ! A moins que... tu ne parlais des mini-PC Chinois ? A base de processeur N100 ou même calibre ? Oui bon là c'est sûr, rien de comparable, ce sont des jouets comparé aux serveurs de gamme pro/enterprise Il n'a jamais été dans mon intention de remplacer mon HP Gen8 Xeon par un N100... et puis après quoi, un Raspberry PI ? Sinon, qu'est ce que tu as voulu dire par DDR-R ? Surement une faute de frappe, mais je ne vois pas quel autre mot convient (pas mémoire DDR-5 puisque là c'est un tout autre problème de stock et donc de prix... heureusement j'ai acheté mes 128 Go de DDR-5 ECC au début de la crise, avant la hausse brutale.... idem pour les 20 To de SSD...)

"Push" ça va t'envoyer une notification sur ton téléphone, si tu veux juste afficher dans la fenêtre de debug tu peux utiliser l'action non documentée "Test". GEA.add ( {CONDITIONS}, 30, "", {"Test", {"Function", function() return "Il y a eu " .. (fibaro.getGlobalVariable("PassToday") or "?") .. " passages aujourd'hui" end} } ) Ou encore mieux directement avec "Function" uniquement : GEA.add ( {CONDITIONS}, 30, "", {"Function", function() print("Il y a eu " .. (fibaro.getGlobalVariable("PassToday") or "?") .. " passages aujourd'hui") end}) Et si tu mets ta variable globale dans les conditions, il y a même moyen de récupérer sa valeur directement avec #value# ce qui permet de l'inclure simplement dans le texte de l'action "Test" ou bien d'une notification. Un truc dans le genre : GEA.add ( {{"Global+", "PassToday", 0}, AUTRES_CONDITIONS}, 30, "", {"Test", "Il y a eu #value# passages aujourd'hui"})

We are excited to share that Silicon Labs has announced a planned acquisition by Texas Instruments (TI), a global leader in semiconductor technology. This combination brings together Silicon Labs’ leadership in embedded wireless connectivity with TI’s manufacturing scale, global reach, and operational excellence. Together, we expect to accelerate innovation, enhance supply reliability, and expand the level of support we can provide to customers worldwide. Importantly, Texas Instruments is acquiring Silicon Labs to build on what we do best. Our product roadmap, customer commitments, and day-to-day operations remain unchanged. Until the transaction closes—expected in the first half of 2027, subject to customary approvals—it is business as usual, and your current contacts and agreements remain the same. We wanted you to hear this directly from us as a trusted customer. If you have any questions, your Silicon Labs representative is happy to discuss what this means for you. Thank you for your continued partnership. We are excited about the opportunities ahead. Sincerely, Brandon Tolany Sr. Vice President Sales & Marketing